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(57) ABSTRACT 

A software system is disclosed which provides for dynamic 
generation of remote proxy classes at run time through a 
distributed object management system 16. The software 
system provides for a client system 14 and server system 12 
which communicate via distributed object management sys- 
tem 16 which operates over a distributed computer network 
to allow communications between client system 14 and 
server system 12. Any inter-object communication will 
invoke a remote proxy generation control module 34 if a 
remote proxy class 23 docs not already exist for the 
requested subject object 18. A remote proxy generation 
control module 34 is provided which first invokes reflection 
engine 36 to determine the applicable information of subject 
class 19. Next, a communication enabling module 40 deter- 
mines and inserts the appropriate computer code to allow 
local object 20 to communicate with subject object 18 
utilizing remote proxy object 22. After the system deter- 
mines what information is required by remote proxy class 
23, byte code generator 42 automatically generates the 
executable code containing remote proxy class 23. Finally, 
class loader 46 loads remote proxy class 23 onto the system 
and creates a new instance which is remote proxy object 22. 
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SYSTEM AND METHOD FOR DYNAMIC client computer system can operate as if it is communicating 

GENERATION OF REMOTE PROXIES directly with a local object The remote proxy object con- 
tains the necessary communications information to allow the 

RELATED APPLICATIONS client computer system to access and manipulate an object 

, 5 which actually exists on the server computer system. 

This application is a continuation of U.S. application Ser. Rcmote rics jJ]ow ^ clicnl systcm to ^ STCg ^ thc 

No. 09/175,079 filed Oct. 19, 1998, now U.S. Pat. No. locat i OQ 0 f the requested object and the communication 

6,385,661. details. 

TECHNICAL FIELD OF THE INVENTION ^ P rox y * s 131 object which has an interface and method 

10 list identical to another object However, it does not contain 

This invention relates in general to the field of software the same detail computer programming. Instead it contains 

systems, and more particularly to an improved system and communications requirements which allow the proxy to 

method for dynamic generation of remote proxy classes communicate directly with another object without the 

within a distributed object management system. knowledge of the first object. Proxies can be used to control 

15 access to certain objects. They may also be used to remove 

BACKGROUND OF THE INVENTION me labor of distributed processing communications from 

^. . . . , • tL j r local objects. For example, if object A which resides on a 

Object oriented programming is a method of program- _ 4 J 4 4 J . • ♦ **u u- . o 

. J ...... 4 . t ci first computer system needs to communicate with object B 

mine which abstracts a computer program into manageable . . . \. J . „ , , _ A m 

r ™ , 5 • . j • • *c which resides on a second computer system, object A must 

sections. The key to object onented programmmg is toe M * ^ ^ ^ 

T C k P ,h c h nca P sulatl0D - E , n h Ca H PSU ,H J 0 " lS S ^puter code to initiate communications with object B 

which the subroutines, or methods, that manipulate data are , T , lL . . , x r e. 

c- j %c *c j i ♦ ■ i *~ p#c *a ♦ Tiv located on thc second computer system. A proxy for object 

combined with the declaration and storage or that data. This _ ♦ / * im n™c ^k;*,* a i« 

, . ii » i f f ,™*i T , c<>.«~ B located on the first computer system allows object A to 

encapsulation prevents the data from arbitrarily being . . . £ f c- » n „ 

j c *c . „ C* „# e simply communicate with the proxy of object B as if object 

accessed by other program subroutines, or objects. When an ,< *\-\ , . tu ,f«nk;^D i,. e 

„ - - , j fc . , j . t • ., s -iii ai ,„j rt(in u fl 25 B resided on the same computer. The proxy for Object B has 

object is invoked, the associated data is available and can be . , K , *^ / #rt „ rtm 

• i * ju r.c *u ^ ,u- u « „ n *th; n a ll lDe necessary mformation and computer code to corn- 
man lpulated by any of the methods which are defined within . ' ^ , 

.c c- * * «c j # tu c ■„ * mumcate with the real object B on the second computer 

the obiect to act upon the data. The basic component ot . , , i t , - A 

encapsulation is a class A class is an abstraction for a set of s y stem - 11115 l W e of P' 0 *? 15 known aS a rem0te pr0Xy SmCC 

encapsulat on is a class. A class u an abstraction lor a set ot computer system remote from the computer 

objects that share the same structure and behavior. An object , n t ... *\ ' t . ... r 

is a single instance of a class that retains the structure and 30 s V slem which re( * uested ob J ect " 

behavior of the class. Objects also contain methods which Systems heretofore known have required all possible 

are the processes by which an object is instructed to perform remote proxies to be built when the software system is 

some procedure or manipulation of data which it controls. "^iaHy compiled and loaded onto a computer This process 

Classes may also be characterized by their interface which „ can be v <*y time consuming and the resultant remote proxies 

defines the elements necessary for proper communication can require large amounts of computer storage. In addition, 

between objects. software system designers must predict every possible 

j ' ii u- * * . remote proxy which may be needed in the future so that it 

Distributed computing allows an object on one computer r . . t . ' a™„ • , , . — . 

ii • # -tu ~a • „il nn can be built when the software system is loaded. This 

system to seamlessly communicate with and manipulate an , . , n tn nAnnt tn ;to 

4 • j • * . . c*c process does not allow a system to adapt to its usage and 

object contained in a second computer system when these 40 v . 7 r to 

computers are connected with a computer network. This env ° 

second computer system may also be referred to as another SUMMARY OF THE INVENTION 
address space. Sophisticated distributed computing systems 

have removed the communications burden from the com- Accordingly, a need has arisen for a software system m 

puter programs, or objects in an object oriented program- 45 me area of distnbuted processing which reduces the time 

ming environment, and placed it in a mid-level operating and expense required to build, load and store a distributed 

system which purpose is to manage communications across object management system. 

a computer network to facilitate a client's access to and According to one embodiment of the present invention, a 
manipulation of data contained on a server system, for software system is provided that comprises a client system 
example, a computer remote to the user in a different address 50 and server system that communicate via a distributed corn- 
space, puter network utilizing a distributed object management 
Distributed computing and object oriented programming ^em. The distributed object management system also 
have led to the development of distributed object manage- comprises a remote proxy generator to dynamically generate 
ment systems. When an object on a client computer system at ™ tirne remote P rox y c l asses as necded for »"er-object 
requests access to an object which exists only on a server 55 communications within the distributed computer network, 
computer system, the distributed object management system One important technical advantage of the present inven- 
steps in to facilitate the communication between the two tion inheres in the fact that it decreases development time 
computer systems and, thus, between the two objects. The and increases developer productivity since the developer 
distributed object management system removes the require- does not have to manually generate the remote proxy classes 
ment of the object on the client system communicating 60 when the system is initially installed or when the subject 
directly with the object on the server system. Instead, current class is modified in the future. Other technical advantages 
distributed object management systems create a remote include reduced initial system build time and reduced disk 
proxy object on the client system which models the interface storage space required to store the application programs, 
of the object which exists on the server system The client DESCRIPTION OF THE DRAWINGS 
computer system which requested access to the remote 65 

object communicates with the remote proxy object which For a more complete understanding of the present inven- 

now exists on the client computer system. Therefore, the tion and the advantages thereof, reference is now made to 
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the following description taken in conjunction with the 
accompanying drawing? in which like reference numbers 
indicate like features and wherein: 

FIG. 1 is a block diagram illustrating a distributed object 
management system constructed according to the teachings 5 
of the present invention; 

FIG. 2 illustrates a flow chart of a method of determining 
when dynamic generation of remote proxy classes is needed 
according to the teachings of the present invention; 

FIG. 3 is a block diagram illustrating dynamic generation 10 
of remote proxy classes according to the teachings of the 
present invention; and 

FIG. 4 illustrates a flow chart of a method of dynamically 
generating remote proxy classes according to the teachings 15 
of the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Referring to FIG. 1, a distributed processing computer ^ 
system generally indicated at 10 is illustrated that comprises 
one or more server systems 12 and one or more client 
systems 14. The client/server computer systems allow for 
decentralized computing which includes the ability to 
manipulate data which is resident on a remote system. The ^ 
server system 12 and client system 14 may comprise a 
personal computer, mini computer, main frame computer, or 
any other suitable computer ■ type device. In a computer 
network environment, each computer is assigned a unique 
address. Therefore, if data, code or objects exist on a 3Q 
different computer, it is said to exist in a different address 
space. 

The client system 14 requests access to data or services 
which may be contained on server system 12. Server system 
12 may then process the request and approve access as 35 
requested by client system 14, Client system 14 is connected 
to server system 12 via a distributed object management 
system 16 operating across a computer network. The dis- 
tributed object management system 16 handles the commu- 
nications between client system 14 and server system 12. 40 
Without distributed object management system 16, distrib- 
uted processing could not take place since client system 14 
would not be able to determine the location of or obtain 
access to the requested data or services. The distributed 
object management system 16 may comprise Voyager, a 45 
distributed network communications system developed by 
ObjectSpace, Inc., CORBA (Common Object Request Bro- 
ker Architecture), a technology for inter-object communica- 
tions developed by a consortium of companies, DCOM, an 
inter-application communications system for networked 50 
computers developed by Microsoft, or any other suitable 
distributed object management system. 

The present invention teaches a system and method for 
generating proxies on local systems to facilitate access to 
objects on remote systems. An object is an instance of a class 55 
within the programming methodology of object oriented 
programming. The present invention may be implemented 
using the Java language, developed by Sun Micro Systems, 
Inc., or any other suitable computer language. 

When an object class source code description is created in 60 
the Java language, it is stored on a storage device as a Java 
file. Upon compilation, the object class executable code is 
represented as a class file on the storage device. When an 
object is needed, a new instance, as prescribed by the .class 
file is created, and it then is referred to as an object. Server 65 
system 12 may contain one or more subject objects 18 for 
which client system 14 may issue a request for access. In 
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such a case, subject object 18 is the subject of client system* s 
14 request. Client system 14 may contain one or more local 
objects 20. It is important to note that local object 20 can 
itself be a subject object, and subject object 18 can itself be 
a local object depending on what computer, or address 
space, is making the request for access. For purposes of 
illustrating the present invention, local object 20 and subject 
object 18 exist in different address spaces. However, both 
local object 20 and subject object 18 could reside on the 
same computer and still invoke the system and method of the 
present invention. The present invention is utilized in all 
inter-object communications regardless of their relative 
locations. 

Local object 20 may request access to subject object 18. 
This request invokes the distributed object management 
system 16. In order to isolate the distributed processing 
communication requirements from local object 20, a remote 
proxy object 22 may be created on client system 14. Remote 
proxy object 22 has an interface and list of methods identical 
to subject object 18. Remote proxy object 22 is so named 
since it may be remote from subject object 18, and it 
provides a local representative for an object which may 
reside in a different address space. Remote proxies in 
general are responsible for encoding a request and its 
arguments and for sending the encoded request to the subject 
object which may exist in a different address space. Remote 
proxies also hide the location of the subject object from the 
requesting local object. Therefore, any local object can 
assume, from an access point of view, that any object it 
needs is local. Local object 20 communicates with remote 
proxy object 22 which then communicates with subject 
object 18 via distributed object management system 16. By 
doing this, local object 20 is unconcerned with the location 
of subject object 18. As far as it is concerned, local object 20 
is communicating direcdy with another local object, but in 
reality, it is communicating with subject object 18 which 
may reside in a different address space. 

Currently, a system developer must anticipate all neces- 
sary remote proxies and create the remote proxy classes. 
Some distributed object management systems have a utility 
which augments the build process by allowing remote proxy 
classes to be built when the system is compiled. Although 
this process minimizes the system developer's effort, it still 
involves developer intervention, computer resources and 
time. Another disadvantage with current distributed object 
management systems is that these remote proxy classes must 
be kept in sync with the subject classes as the subject classes 
and interfaces are modified. Another disadvantage with 
current distributed object management systems is that all 
remote proxy classes must be stored on the computer and 
available for use when needed. This creates high overhead in 
developer effort, computer storage and processing require- 
ments. 

In contrast, a system constructed using the present inven- 
tion dynamically generates remote proxy classes as needed 
at run-time. There are several advantages of this method. 
The primary advantage is reduced system development time 
since the system developer does not have to manually 
generate remote proxy classes when the system is initially 
compiled or manually regenerate remote proxy classes each 
time a subject object class is modified. The system of the 
present invention also reduces computer program storage 
requirements since remote proxy classes are not a permanent 
part of the operating environment. It also minimizes compile 
and load time for the computer program since remote proxy 
classes do not have to be generated at compile and load time. 
In order to optimize system performance, generated remote 
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proxy classes remain in memory until the distributed object 
management system is shut down. 

Referring again to FIG. 1, the dynamic generation of 
remote proxies may be accomplished by parsing the .class or 
.java file for subject object 18 and creating a .java file for 
remote proxy object 22 which contains the interfaces and 
methods of the subject object 18. The Java compiler may 
then be invoked to compile the .java file into a .class file for 
remote proxy object 22. The compiled .class file can then be 
loaded into the computer system via a class loader which is 
a standard element in a Java environment. A .class file must 
be loaded before it is available for use by distributed 
processing computer system 10. Once the .class file is 
loaded, a new instance of the compiled .class file may be 
created which will be remote proxy object 22. 

The process of parsing the subject object 18 class (subject 
class 19) or .java file, creating a source code file for remote 
proxy class 23, compiling, loading, and creating a new 
instance may be excessively slow at run-time. In order to 
address this issue, a reflection process may be used on 
subject object 18 to determine its name, interfaces and list of 
methods and then to directly generate the byte codes into a 
.class file, subject class 19. The byte codes are the executable 
code stored in a .class file. The .class file can then be loaded 
into the computer system with the class loader. This embodi- 
ment eliminates the need to parse the .class file, create a java 
source code file, and shell out the .java file to a compiler 
since the code generation process occurs as part of the 
dynamic generation of remote proxies. This entire process of 
dynamic generation of remote proxies will be discussed in 
detail with reference to FIGS. 2, 3 and 4. 

Referring to FIG. 2, the process of determining if a remote 
proxy is necessary is invoked via a request from local object 
20 for access to subject object 18. The method begins at step 
24 where local object 20 on client system 14 requests access 
to subject object 18 on server system 12. This request could 
be for any object whether it is local or remote and in a 
different address space. The system of the present invention 
generates and utilizes remote proxy objects in all inter- 
object communication to provide additional processing sup- 
port. Thus, any communication between objects, regardless 
of their location, utilizes remote proxy objects. These remote 
proxy objects act as a middle man between the requested 
object and the requesting object to provide additional pro- 
cessing functionality which may include increased security. 

Referring again to FIG. 2, the method then proceeds to 
step 26 where the requested object is located on either client 
system 14 or server system 12. The method proceeds to step 
30 where a determination is made regarding the need for a 
remote proxy class. If remote proxy class 23 already exists 
on client system 14, then the method terminates since remote 
proxy classes are not removed from client system 14 until 
the distributed object management system 16 is shut down. 
However, if remote proxy class 23 does not exist on client 
system 14, the method then proceeds to step 32 where 
remote proxy class 23 is generated on client system 14 based 
on the name, interfaces and methods of subject object 18 
which may reside on either server system 12 or client system 
14. The method for generating these remote proxies is 
described in detail with reference to FIGS. 3 and 4. 

FIG. 3 is a functional diagram of the portions of distrib- 
uted object management system 16 that are used to create 
remote proxy classes as necessary. Remote proxy generation 
control module 34 is invoked at step 32 in FIG. 2. When the 
distributed object management system 16 invokes the 
remote proxy generation control module 34, the method 
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described previously has already determined that the remote 
proxy class 23 does not yet exist on client system 14. 
Remote proxy generation control module 34 generates 
remote proxy 22 on client system 14 so local object 20 can 

5 communicate with subject object 18 via distributed object 
management system 16. 

As previously discussed, in object oriented programming, 
an object is an instance of a class. Classes may be defined 
in a class hierarchy where each class inherits the attributes 

10 of all of its ancestors. Inheritance is a concept which maps 
related classes onto each other in a hierarchical way. This 
allows a descendant of a class to inherit all of its variables 
and methods from its ancestors as well as create its own. The 
immediate ancestor of a class is known as its superclass. 

* 5 Therefore, in order to determine all of a class's attributes, all 
of the class's ancestors, or superclasses, must be determined. 

To fully define a remote proxy for a subject object, remote 
proxies must be generated for each of the subject object's 
superclasses. By generating these superclass remote proxies, 

20 the remote proxy for subject object will inherit all of the 
variables and methods of its ancestors, or superclasses. An 
alternative to generating superclass remote proxies includes 
adding all of the superclass methods and interface require- 
ments to the remote proxy class. By adding the superclass 

25 information to the remote proxy class, the need for gener- 
ating superclass remote proxies is eliminated. 

Referring again to FIG. 3, remote proxy generation con- 
trol module 34 first invokes reflection engine 36 to deter- 

30 mine information regarding subject class 19. The process of 
reflection operates on subject class 19 which is the Java 
.class file for subject object 18. Although for illustrative 
purposes, subject object 18 and its Java .class file, subject 
class 19, exist on server system 12, subject class 19 could 

35 exist on either client system 14 or server system 12. 
Therefore, the dynamic generation of remote proxy classes 
as described in the present invention could take place on 
either client system 14 or server system 12. 

Reflection is a process that determines what an object can 

4 0 do, how it is defined, and how it communicates with other 
objects. Reflection mirrors the public view of an object to 
collect information to facilitate the creation of proxies which 
resemble objects on the public view, but are very different 
internally, or privately. The public view of an object repre- 

45 sents the information external objects must know in order to 
communicate with the first object. Proxies need to be 
reflections, or duplicates on the surface, of objects since 
proxies perform specific tasks such as controlling access to 
or communications with the objects they represent. Thus, 

50 proxies need to look like the object on the outside, but on the 
inside, proxies contain unique computer code to accomplish 
their assigned function. The reflection process is only con- 
cerned with determining the public view of an object. 
Therefore, the information determined by the reflection 

55 process includes the following: name; list of implemented 
interfaces; list of methods; and superclass information. 

Continuing with FIG. 3, reflection engine 36 issues que- 
ries against subject class 19, which is the .class file for 
subject object 18, to determine each of subject class 19 

60 superclasses, its name, its interfaces, and each of its meth- 
ods. The results of these queries are temporarily stored 
within remote proxy generation control module 34 as JCIass 
information 38. JCIass information 38 is a temporary storage 
area which defines the name, superclasses, interfaces, and 

65 methods of subject class 19. JCIass information 38 would 
also include the name, interfaces, and methods of each of 
subject class 19 superclasses. 
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If subject class 19 has superclasses, a remote proxy may code generator 42 is constructed in such a way that the byte 

be first generated for each superclass using the system and codes are generated in the sequence required by the Java 

method described with reference to the present invention. virtual machine. 

After the superclass remote proxies are generated, JClass For each Java 0^™^ byte code generator 42 writes the 

information 38 contains the name, interface, and list of 5 appropriate header information and hexadecimal byte codes 

methods for subject class ^IS I. An alten^te methodology for representing me Java construct into computer memory, 

providing superclass methods and mterfaces for the remote ^ ^ fc a Wock of ^ Qr hcxadccimal b tcs , for each 

proxy c ass is to add afl superclass method and interface Jaya dc&crihcd ab jciass mformation 38 

information to the remote proxy class. By doing this, the .... j c ■ *• 

, r , 1* - - v • \ a contains the computer code necessary for communications 

need tor separate superclass remote proxies is euminaxa. ,„ manae emen t syste m 16. Bvte code 

Once the name, interface methods, and superclass infer- tQr 42 ^ communications information 

mation are determined for subject c ass 19 a communication ^ b ^ f ^ble to the Java virtual machine, 

enabhng module 40 adds to JClass mformation 38 the fe ^ generator 42 terminates, the string of 

computer code necessary for remote proxy object 22 to hexadecimaJ b tes necessary to define the proxy class has 

communicate with subject object 18 via distributed object J5 beeQ stQred in memory ^ remote x class 23 which ^ an 

management system 16. TTje commumcaUon enablmg ,mod- executaWe Java >class file> Remo te proxy class 23 has a 

ule 40 inserts the computer code into JClass information 38 . ue name ^ derived from subjecl dasg 19 ^ 

which is the definition of all the information that remote For k tf ^ ^ 19 fa namcd « Foadas8 n its 

proxy object 22 needs to function within distnbuted object remote ^ ^ Qame wouM be « Foo _ ProX y.class-. 

management system 16. on n * . . . 

*\ , . . Before remote proxy class 23 can be used, it must be 

Since a remote proxy s purpose is to communicate with a , , , A f \ u iT . 1 1 j ac 

• . . . . . l * i_ -4U j-ff ♦ jj „ loaded onto chent system 14 utilizing a class Loader 46. 

subject object which may exist either in a different address . r 7 . -wMt *™u^ * „, ; ^ K1- 

• ,u , f . . ™ v „ Class loader 46 may comprise any number of suitable 

space or in the same address space, the remote proxy ... • • ♦ • 1 u - » • * a ~ « 
r t . „ 1 a. « 11 • ■ * ™ »• * programs which exist m typical object oriented program- 
contains essentially only the following mformation: mter- * . & , ^ , , - J ^ ■„ tK :„ ° nt » 

c . j j » 1 .1 « • i 1 * j i- * * mine environments. The class loader 46 will then create 

faces identical to the subject object; a list of methods 25 , w u- u- * * _ nf ^ :r 

identical to the subject object; and computer code necessary * remote proxy object 22 which K anjns tana ^ of remote proxy 

for the remote proxy to communicate with the subject object. class 23 S enerated b y wd6 &™ &to1 42 ; 

In an alternate embodiment of the present invention, the FIG. 4 is a flow diagram that illustrates the process of 

remote proxy would contain all of the information men- generating a remote proxy when invoked by step 32 in FIG. 

tioned above and the interfaces and methods of all of the 30 2 and 88 represented in genera by the block diagram in FIG. 

subject object's superclasses. 3 - ^ rnethod be S^ s at ste P 48 where the reflection engine 

At this point, JClass information 38 contains subject 38 *»™» sub i ect cl ? s * 19 , t0 * ten ? ine ite * u P erc . las f; ^ 

object's 18 name, interfaces, methods, and the computer me *° d ^proceeds to step 50 where a deterrnmat.on .s 

code necessary for communications within distributed made regarding the existence of a superclass for subject 

object management system 16. JClass information 38 could 3 s a superclass is found for subject class 19, then the 

also containThe superclass information for subject object 18. rnethod proceeds to step 52 where a determination is made 

The next function invoked by remote proxy generation regarding the existence of the remote proxy class on client 

control module 34 is byte code generator 42. The purpose of ^ 14 representing subject class 19 superclass. If a 

byte code generator 42 is to directly generate the executable remote proxy class does not ex* for subject class 19 

code corresponding to JClass information 38. JClass infer- «o su P erelass . mcth °? Proceeds to step 54 where the remote 

mation 38 is the definition of the Java class of which remote P rox y * generated for subject class 19 superclass by 

prox y object22i S aninstance.n.atis,JCla S sinformation38 recursively invokmg the remote proxy generation oontnd 

■ .i. j r r * „ i d ~~a~ module 34. Thus, step 54 recursively invokes the method 

is the definition of remote proxy class 23. Byte code !r . " ' ± v 7 

generator 42 reviews JClass information 38 and generates illustrated in HCj. 4. 

the corresponding byte codes, or executable code, into 45 Referring to step 52, if the remote proxy class does exist 

remote proxy class 23 which is a Java .class file. As on chent system 14 for subject class' 19 superclass, then the 

previously discussed, a Java .class file is executable code method proceeds to step 56 (described below) since remote 

which defines a Java class. P rox y classes exist for aU of sub J ect object's 18 

Byte code generator 42 is a collection of Java classes superclasses, 

which are capable of taking the description of the needed 50 In an alternate embodiment of the present invention, 

proxy class in JClass information 38 and directly generating instead of recursively generating remote proxy classes for 

the executable Java code in memory. The function of byte each of subject class 19 superclasses, the interfaces and 

code generator 42 is similar to that of a Java compiler, like methods of each of subject class 19 superclasses are stored 

a Java compiler, byte code generator 42 generates execut- m JClass information 38 and are later used in the generation 

able Java code. However, the inputs are very different. A 55 of remote proxy class 23. In me alternate embodiment, steps 

compiler requires a source code file which is a string of bytes 48-54 would not exist in their current form. Instead, these 

which is the sequence of statements for a Java object steps would consist of determining the names, interfaces, 

definition. The string of bytes is parsed by the Java compiler *n d methods of all of subject class 19 superclasses and 

and translated into executable Java code. In contrast, byte storing the information in JClass information 38. 

code generator 42 takes general information regarding the 60 Referring to step 50 if a superclass does not exist for 

needed Java object and directly generates executable Java subject object 18, then the method proceeds to step 56 where 

code without the need for the intermediate step of creating reflection engine 36 queries subject class 19 to determine 

a Java source file. This technique yields considerable time subject class* 19 name and interface. The method then 

savings since several steps are omitted. For example, like a proceeds to step 58 where reflection engine 38 queries 

Java compiler, byte code generator 42 generates a hexadeci- 65 subject class 19 regarding its methods. Reflection engine 36 

mal "CAFEBABE" to indicate to the Java virtual machine issues queries for each of subject class 1 19 methods until all 

that a Java, class file begins at that point in memory. Byte methods are determined. For each of subject class* 19 
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methods, the software system determines the method name, 6. The system of claim 1, wherein the first address space 

return type, parameters, and exceptions and stores the infor- is in a server system and the second address space is in a 

mation in JClass information 38. client system. 

The method then proceeds to step 60 where reflection ? ^ syslem of claim x where i n lhe control module is 

engine 36 creates JClass information 38 from the name 5 We te a class for each 

interface, and methods mformation detennmed in steps 56 *^ . .f , j t- . 

and 58. The method then proceeds to step 62 where com- associated with the requested object, 

munication enabling module 40 inserts in JClass informa- 8. The system of claim 1, further comprising: 

tion 38 the computer code, in the form of an expression tree, a class loader operable to load the proxy class into the first 

necessary for remote proxy object 22 to communicate with 30 address space 

subject object 18 via distributed object management system 9 ^ &ys{cm Qf ^ x whcfcm ^ structure of thc 

L, iL , A , j . * u l • -i requested object determined by the reflection engine 

The method then proceeds to step 64 where byte code . \ , i A A . ' ... .« 

generator 42 generates the executable code representing includes methods and ^^rfaces associated with the 

JClass information 38 into remote proxy class 23. The requested object. 

method then proceeds to step 66 where class loader 46 loads 10. The system of claim 7, wherein the structure of the 

remote proxy class 23 onto client system 14 where it is now requested object determined by the reflection engine 

available for use. The method then proceeds to step 68 where ^chides methods and interfaces associated with a superclass 

remote proxy object 22 is generated asanew instance of of ^ f ^ QbjecL 

remote proxy class 23 which was loaded m step 66. ^ _^ J , . . « , 

j. . . * - 4 . , . r in U. The system of claim 1, wherein the proxy class is 

According to the teachings of the present invention, a . * , V, , . . r 

software system is provided that allows for the dynamic dynamically generated as needed during run-time of an 

generation of remote proxy classes. The advantages of executing computer program. 

dynamic generation of remote proxy classes includes 12. A method for generating a proxy class in a computer 

reduced system development time, reduced system compile environment, comprising: 

and build time, reduced system modification time, and 25 . . if . - . r 

j ~r " V ? t n ; receiving an access request from a first address space for 

reduced system storage requirements. Remote proxy classes B ™ L . . ^ 

are generated as needed at run time. Once a remote proxy a requested object m a second address space; 

class is generated, it continues to exist until the system is locating the requested object; 

shut down. Therefore the software system is only required determining a structure of the requested object; 

to generate a particular remote proxy class once during a 30 

session of the software system. generating communication code to facilitate communica- 

Although the present invention and its advantages have tions with the requested object; 

been described in detail, it should be understood that various generating executable code from the structure and the 

changes, substitutions and alterations can be made therein communication code* 

without departing from the spirit and scope of the invention „ . ' . 

as defined by the appended claims. loadm g the executable code into a remote proxy class at 

What is claimed is: the first address space. 

1. A proxy generator for generating a proxy class in a 13. The method of claim 12, further comprising: 
computer environment, comprising: creating a remote proxy object associated with the remote 

a control module operable to receive an access request 4Q proxy class 
from a requesting object in a first address space, the u ^ mcthod of daim n com ^ 
access request identifying a requested object m a sec- 
ond address space, the control module operable to determining whether a remote proxy class exists for the 
facilitate communications between the requesting requested object. 

object in the first address space and the requested object 45 15. The method of claim 12, wherein determining the 

in the second address space; structure of the requested object includes: 

a reflection engine operable to determine a structure of the issuing a query to the requested object; 

requested object for use in creating the proxy class; . . , - m . M „„.„i 

M J receiving a response to the query from the requested 

a byte code generator operable to generate computer code . ° 

nwte&'Jt* rCprCSCnting lhC StrUCtUrC ° f 50 16° Ue method of claim 12, wherein determining the 

2. The system ofclaim 1, further comprising: struclure of rec * uesled mcludes: 

a determination module operable to determine if a proxy identifying any superclasses associated with the requested 

class needs to be generated in response to an access object; 

request from the requesting object in the first address 55 retrieving superclass information associated with any 

space. identified superclasses of the requested object. 

3. The system of claim 1, further comprising: 17, The method of claim 12, wherein the remote proxy 
a communications module operable to insert computer class is dynamically generated and loaded as needed during 

code within the proxy class to enable communications run-time of an executing computer program. 

between the requesting object in the first address space 60 18. A system for generating a proxy class in a computer 

and the requested object in the second address space. environment, comprising: 

4. The system of claim 1, wherein the first address space , , m - cnn ^ • . 
is in a client system and the second address space is in a a firet address *? at * ■ addreSS *"* lDcludmg a 
server system. requestmg object; 

5. The system of claim 1, wherein the first address space 65 a second address space, the second address space includ- 
is in a first computer system and the second address space is ing a requested object with which the requesting object 
in the first computer system. wishes to communicate; 
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a proxy generator operable to receive an access request 
from the requesting object, the proxy generator oper- 
able to facilitate communications between the request- 
ing object and the requested object in response to the 
access request, the proxy generator operable to deter- 
mine a structure of the requested object, the proxy 
generator operable to create a remote proxy class 
associated with the structure of the requested object, 
the proxy generator operable to load the remote proxy 
class into the first address space. 
19. The system of claim 18, wherein the proxy generator 

is operable to generate communication code for the remote 

proxy class. 
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20. The system of claim 18, wherein the proxy generator 
is operable to determine methods and interfaces associated 
with the structure of the requested object. 

21. The system of claim 18, wherein the proxy generator 
is operable to determine whether a remote proxy class 
associated with the requested object has previously been 
generated in response to an earlier access request. 

22. The system of claim 18, wherein the remote proxy 
generator is operable to determine superclass information 
associated with the requested object. 
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